home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000071_kane@sonata.cc.purdue.edu_Wed Oct 20 13:33 MDT 1993.msg < prev    next >
Internet Message Format  |  1994-10-30  |  7KB

  1. Received: from yvax.byu.edu by maine.et.byu.edu; Wed, 20 Oct 93 13:33:23 -0600
  2. Return-Path: <kane@sonata.cc.purdue.edu>
  3. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.2-13 #4169) id
  4.  <01H4C5G2EG0094HF9E@yvax.byu.edu>; Wed, 20 Oct 1993 13:31:22 MDT
  5. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.2-13 #4169) id
  6.  <01H4C5FXH7009BWI0Q@yvax.byu.edu>; Wed, 20 Oct 1993 13:31:15 MDT
  7. Received: from yvax.byu.edu by alaska.et.byu.edu; Wed, 20 Oct 93 13:32:33 -0600
  8. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.2-13 #4169) id
  9.  <01H4C5F2R45S94HF9E@yvax.byu.edu>; Wed, 20 Oct 1993 13:30:34 MDT
  10. Received: from sonata.cc.purdue.edu by yvax.byu.edu (PMDF V4.2-13 #4169) id
  11.  <01H4C5EP6U7K9BWJ06@yvax.byu.edu>; Wed, 20 Oct 1993 13:30:26 MDT
  12. Received: from toccata.cc.purdue.edu by sonata.cc.purdue.edu (5.61/Purdue_CC)
  13.  id AA08319; Wed, 20 Oct 93 14:30:10 -0500
  14. Received: by toccata.cc.purdue.edu (NX5.67d/NX3.0X) id AA05873; Wed,
  15.  20 Oct 93 14:30:04 -0500
  16. Received: by NeXT.Mailer (1.95)
  17. Received: by NeXT Mailer (1.95)
  18. Date: Wed, 20 Oct 1993 14:30:04 -0500
  19. From: kane@sonata.cc.purdue.edu
  20. Subject: More comments on the MiscKit license (long long)
  21. To: misckit@byu.edu
  22. Message-Id: <9310201930.AA08319@sonata.cc.purdue.edu>
  23. Content-Transfer-Encoding: 7BIT
  24. Status: RO
  25.  
  26. Below I include some final thoughts on the MiscKit license,
  27. before Don locks it up, in no particular order.  Mostly these
  28. are directed to Don, but others might be interested in some
  29. of them as well. (Probably not, but, who knows?)
  30.  
  31.  
  32. jgrace@tetrasoft.com said:
  33. > I would prefer partial kit distribution be allowed.
  34.  
  35. Ah, but you are forgetting the founding principle of the
  36. MiscKit:
  37.       Ash ghatk durbatulu^k, ash ghatk gimbatul, ash ghatk
  38.       thrakatulu^k agh burzum-ishi krimpatul!
  39.  
  40.       [One kit to rule them all, one kit to find them, one
  41.       kit to bring them all and in the darkness bind them.]
  42.     -- paraphrased from "The Fellowship of the Ring",
  43.                                          J. R. R. Tolkien
  44.  
  45. The Kit isn't that big.  Yet.  But this is something to
  46. keep in mind.  Maybe when the Kit hits 4MB, we should bring
  47. this up again. :-)
  48.  
  49. A suggestion: I have come to the opinion that the
  50. MiscKit license is way too big and daunting.  This was in
  51. my mind when I recommended to Don to split the explanatory
  52. material away from the license itself.  Now, I suggest
  53. going a bit further: everything from just above the line
  54. "This is the end of the formal MiscKit License Agreement."
  55. to the end of version 0.3 of the license should be removed
  56. from the license, and put in a separate document.  This
  57. separate document could be distributed with the MiscKit,
  58. or the administrator could retain it, using it to answer
  59. questions when they arise.  As a description of a philosophy,
  60. rather than specific requirements, it doesn't belong with
  61. the license itself, I would argue.  Perhaps a file
  62. LICENSENOTES.rtf in the distribution would be appropriate.
  63. Anything point that _requires_ the explanatory material
  64. isn't stated well in the license itself.
  65.  
  66. Putting the administrators telephone number and US mail
  67. address in the license may be a good idea, but won't it
  68. necessitate a new version of the license anytime that the
  69. administrator decides to move?  Remember that older versions
  70. of the MiscKit don't disappear when a new one is released,
  71. and perhaps even continue to be distributed, so multiple
  72. conflicting addresses may be the result (if Don decides to
  73. move a few times in the next couple years).
  74.  
  75. Trivial: Don't indent the three paragraphs in the top part
  76. of the license.  There's already vertical whitespace.
  77.  
  78. jgrace@tetrasoft.com wrote:
  79. > Again, are these restrictions on media format necessary and
  80. > desirable?  [...] Also, the license could then avoid
  81. > arbitrarily defining what constitutes "mass media" today [...]
  82.  
  83. I have also made this (second) comment to Don, but could think
  84. of no alternative that satisfied his reasons for including it,
  85. nor a good argument against having it there in the first place.
  86. Fortunately, Joe has put his finger right on the essence of the
  87. answer for me:
  88.  
  89. > [...] if someone violates these restrictions, is this really
  90. > a battle MiscKit administrators and owners would care to fight
  91. > to the finish?
  92.  
  93. It seems to me that the more restrictions that are present in
  94. the license, the more likely it is that someone will choose
  95. to violate one or more of them (but that's not a linear
  96. relation, I think :-)).  It requires effort to fight violations;
  97. shall we state a restriction we are not prepared to defend?
  98. Don makes his arguments for this restriction, but he also uses
  99. the words "the MiscKit should be"; "should" is not stating a
  100. requirement, it is making a suggestion.  And what is this
  101. "These restrictions apply to...official MiscKit distribution"
  102. at the top of point 3?  So if I create an unofficial version
  103. of the MiscKit (and satisfy point 2), I am exempt from these
  104. "requirements"?  Finally in point 3d, "any other electronic
  105. means" is a very broad statement, which might be argued to
  106. nullify points a,b,c: certainly a CD or floppy is "electronic
  107. means" in that I must use an electronic device to make use
  108. of the media; a floppy disk is useless without a floppy drive,
  109. and a floppy drive has no use with out a floppy disk.  From
  110. a physical point of view, electricity and magnetism 2 sides
  111. of the same coin (as it were). Etc., etc.....  Eliminate
  112. section 3 would be my suggestion.
  113.  
  114. Another note, something that just occured to me: one purported
  115. goal of the license is to 'promote' the MiscKit, to 'get it known'.
  116. But I think point 3b may quelch some enterprises that may do just
  117. that; hence more apparent contradictions in the license and its
  118. philosophy.  About Don's point regarding "gullible folk": But
  119. Don!  That's the American Way. :-)  Saving "gullible folk" from
  120. themselves is a noble gesture, but....
  121.  
  122. lindberg@cs.colgate.edu wrote:
  123. > On mandating an uncompressed redistribution [...]
  124. > One would think that the people buying the distribution would
  125. > determine how the distributor handles such issues.  I say leave
  126. > this to the distributor.  I think it's up to them to determine
  127. > what people want (it's in their interest, after all).
  128.  
  129. Another good point.  A market economy will take care of this,
  130. (simplistically), in the absence of a monopoly, and in the
  131. presence of obtainable information about the various products.
  132.  
  133. In point 9: "When approval is requested, failure to respond
  134. within two weeks of such a request constitutes a "YES" vote."
  135. This should be in the charter, not the license.
  136.  
  137. Joe also said:
  138. > Perhaps this 'marking' could simply be a requirement to include
  139. > the MiscKit License Agreement with any and all distributions.
  140. > This is the approach GNU takes.  This approach would ensure
  141. > the 'marking' were comprehensive and not just superficial.
  142.  
  143. The GNU license requires more than simply including the license,
  144. but that's not important.  This is a good suggestion.
  145.  
  146. Otherwise, looks like things are shaping up.
  147.  
  148. Christopher Kane
  149. kane@cs.purdue.edu